1. Field of the Invention
The present invention relates to a communications device that is connected with USB connection to a host device and a communications method thereof, and in particular, relates to controlling a buffer-full state when achieving virtual serial communication in a universal serial bus (USB) interface that can be applied to, for example, a point of sale (POS) system where a host device and a printer are connected with USB connection.
2. Description of the Related Art
FIG. 10 is a diagram for explaining the conventional relationship between host devices and printers. For example, in a conventional POS System, the computer that is provided with the host device is structured from an application program 202, such as POS or cash register software, and an operating system part. The operating system performs input/output through an application program interface (API) 203, and through a device driver such as a parallel interface driver 207 or serial interface driver 205, with a parallel port 209, such as an IEEE 1284, or a serial port 208, such as an RS-232, to perform communications with a printer 201. Moreover, in some cases the connection is through a USB printer class driver 204 or a USB bus driver 206.
In recent years computers and peripheral devices (printers) that do not have so-called “legacy” ports such as the IEEE 1284 parallel port or the RS-232 serial interface, but rather only have the USB interface, which has superior cost/performance, have become very popular.
On the other hand, in existing applications there are still many software resources that use the legacy ports, and cannot use USB devices directly, so it is necessary to convert these to applications that use USB interfaces, which involves a great deal of work.
Typically, in serial interfaces, the Xon/Xoff protocol and request to send/clear to send (RTS/CTS) protocol, and the like, are typically used as data flow control. FIG. 11 is a flowchart for the printer side for explaining data flow control in a serial interface.
For example, when data is received on the printer side (S101), if the state of the buffer, or the like, is one wherein reception of data is not possible (S102), then an Xoff code is sent, or the CTS signal is turned OFF, or the like, requesting the host computer to stop sending (S103). In contrast, when the buffer is empty (S104), the Xon code or CTS signal is turned ON to request that sending be restarted (S105). The host computer constantly monitors the CTS Signal or Xoff code to stop or restart sending according to the request.
However, when in a buffer-full state, no data can be received, so at such a time no cash drawer command can be sent, so the drawer cannot be opened. Given this, when the drawer is to be opened, the application instructs the serial interface driver to temporarily not perform flow control, to thereby force the drawer command to be sent in a state wherein the Xoff code and CTS OFF notifications are not monitored.
Even in a USB interface, there is a problem that when the receive buffer is in a full state, receive data cannot be received.
In the USB interface, communications are performed by sending data in packets, and responding with an ACK/NAK for each packet. As with the legacy serial interface, when the buffer is in a full state, the data cannot be received, and an NAK is returned. When the host computer receives the NAK response from the printer, the data packet is resent. This operation is repeated until either a timeout or until an ACK response is received.
In this state, if one wishes to send a drawer command, the data packet and the NAK response are repeated, so the drawer command cannot be sent. In this way, the USB interface is constrained to perform flow control using ACK and NAK responses, and the Xon/Xoff protocol and RTS/CTS flow control are not performed. Because this is not a protocol wherein flow control is not performed, there are no means by which to force data transmission when the printer is in a state wherein data cannot be received, such as is possible in a serial interface, and thus when in a buffer-full state, it is not possible to send commands that have high importance, such as drawer commands.
FIG. 12 is a diagram for explaining the state of communications between the host and a peripheral device using the USB interface. Note that the figure shows the details of the processes performed by the CPU on the peripheral device side, and the state of storage of data in the receive buffer.
FIG. 12A shows the case wherein there is adequate free space in the receive buffer of the peripheral device. When send data is sent from the host side when the receive buffer is in that state, the send data is stored in the receive buffer on the peripheral device side, and an ACK response is sent to the host side to provide notification that the data was received correctly. The host side receives the ACK response to confirm the successful reception.
On the other hand, FIG. 12B shows the state wherein there is not adequate free space in the receive buffer of the peripheral device. When send data is sent from the host side when there is not adequate space in the receive buffer, the peripheral side denies storage of the send data to the receive buffer, and sends an NAK response to the host side to provide notification that the send data was not accepted. After the host side receives the NAK response to confirm that the send data was not accepted, the host side resends the send data. The host repeatedly resends the send data until an ACK response is received.
In this way, even in a USB interface, if the receive buffer of the peripheral device is in a buffer-full state, then receive data cannot be received, so that if, for example, the peripheral device is a printer, then when an error occurs such as being out of paper, there will be a problem in that the peripheral device will not be able to receive a drawer command or a status check command.
Given this, in Japanese Unexamined Patent Application Publication No. H10-333856 a structure is proposed wherein, in a communications terminal, a mode 1 is provided that outputs a busy signal to indicate to the host side that data cannot be processed, and provides a mode 2 that does not output a busy signal and that receives from the host side commands to be processed, where the mode 2 is set for applications that handle commands in real time to thereby enable the handling of a hold state or error state by the host-side application software.
Japanese Unexamined Patent Application Publication No. 2000-207142 identifies the problem that it is not possible for a higher-level device to receive send data that is sent from a printer device when the receive buffer is full when data transmission is performed using the extended capability port (ECP) mode defined in IEEE 1284 in the interface between the higher-level device and the printer, and as a solution to this problem, describes preventing the receive buffer of the printer device from becoming full by the higher-level device not sending the next print data until receiving notification from the printer device of the size that can be received. There is a description of the size that can be received being changed by a specification on the printer device side, to optimize the size that can be received to match the transmission performance of the higher-level device.
In recent years, in POS systems, and the like, communications between the host device and the printer have been performed through a USB instead of the aforementioned RS-232C or IEEE 1284 communications, or the like. In this communication using USB, preventing a memory overflow when the remaining memory of image memory is small through determining the magnitudes of remaining memory and a threshold value when receiving an OUT packet, and responding with an NAK handshake and refusing to receive the data if the remaining memory is smaller than the threshold value is proposed in, for example, Japanese Unexamined Patent Application Publication No. 2005-117422.
Moreover, a structure wherein a buffer-full is prevented in parallel communications control by establishing specific special commands on the printer side and providing on the host side special command processing means when specific error states, established in advance, occur is proposed in, for example, Japanese Unexamined Patent Application Publication No. 2005-18638.
Moreover, Japanese Unexamined Patent Application Publication No. 2001-202322 proposes an interface device for connecting between a host device and a printer device wherein the host device is caused to send data, even if the printer device cannot receive data, if the receive data is a real-time command, and the data is stored to a storage means and sent to the printing device and applied to the receive buffer of the printing device.
In a POS system wherein a control is performed by a host device, typically the structure is one wherein the host device is connected to a printer, and connected through the printer to a variety of data terminals such as a display device, a drawer, a modem, a barcode reader, and so forth, where the data that is sent to the variety of data terminals is first sent from the host device to the printer, and then sent from the printer to the individual data terminals.
Moreover, when, in a POS system that uses serial communications, there is a switch over to communications using a USB from a conventional serial communications port, it is desirable to reduce the costs incurred in the change by having the changes from the existing device structure, used in conventional serial communications, be as small as possible in the structure of the host device side PC and the printer on the terminal device side.
Given such a desire, various approaches, such as described above, have been proposed for the problem of not being able to receive commands to be executed immediately if the communications device side receive buffer is in a buffer-full state in the data communications between the host device and the communications device as described above. However, all of these approaches are handled by having specialty functions on the communications device side, but switching software requires a vast amount of work, and there is also the problem of low general versatility, such as having to prepare an interface device having special functions, as well as the problem of not having a solution that uses the functions that are normally provided in normal communications equipment.
Furthermore, in the structure in Japanese Unexamined Patent Application Publication No. H10-333856, there is a problem in that even though it is necessary to have a mode selecting function on the communications terminal side, this cannot be applied to application software that does not respond in real time.
Additionally, the structure in Japanese Unexamined Patent Application Publication No. 2000-207142 must have a function to detect the size that can be received by the printer device and to transfer to the higher-level device the receivable size that has been detected, and thus it is necessary to incorporate a new function into existing communications devices that do not have this function. Moreover, although it is possible to change the size that can be received, it is necessary for this change to be performed on the printer device side, and thus necessary to incorporate the receivable size change function into the printer device side. There is also a problem in that the change to the receivable size cannot be performed on the higher-level device side.
In the structure in Japanese Unexamined Patent Application Publication No 2005-117422, the reception of image data is refused when the remaining memory is less than a threshold value, and thus there is a problem in that reception of commands requiring real-time execution is also refused, making it impossible to execute real-time execution commands in the communications device.
The structure in Japanese Unexamined Patent Application Publication No. 2005-18638 has a problem in that the host side is provided with specialty command processing means, so it is necessary also to have a function to execute the specialty commands on the printer side as well.
In the structure in Japanese Unexamined Patent Application Publication No. 2001-202322, there is the problem of the need to provide, in the interface device, a function for determining whether the receive data is a received-data real-time command, and the need to provide storage means for storing received-data real-time commands.
As described above, because all of the systems disclosed in the above-described patent literature require major changes, such as adding new devices or functions, to the host side and the communications device side, it is difficult to enable the reception of real-time execution commands when the receive buffer is in a buffer-full state without requiring major changes in the existing host device or communications device.
Because of this, when applying, to the receive buffer-full state, the conventional technology that has been proposed, there is the problem of requiring new structures or functions in the host-side PC or the terminal equipment-side printer.
Consequently, there is the need to be able to receive real-time execution commands, even when the receive buffer is full, in a configuration that uses the existing device structure, without adding new structures or functions to the host-side PC or the terminal equipment-side printer.